Digital certificates are in wide use on the Internet and in the field of electronic commerce for authentication of all sorts of electronic transactions. In general, such digital certificates are used to certify the identity of an entity in the digital world, particularly as defined by the public key infrastructure (PKI). As digital certificates are issued and used, they often are either revoked or expire after a predetermined amount of time. In other situations, a digital certificate may be revoked or placed on hold pending some event. In order for digital certificates to be useful, it is important that those entities using digital certificates to authenticate the identity of an entity presenting the digital certificate have confidence that the digital certificate is valid. Generally, the validity of a digital certificate can be determined by reference to a Certificate Revocation List (CRL) produced by an authority that generates the certificates (usually a Certificate Authority).
FIG. 1 depicts a simple exemplary computer network 100 that utilizes a digital certificate and a Certificate Revocation List. In system 100, a user terminal 104 may request via a network (for example the Internet) 108, a digital certificate from a Certificate Authority 112. The Certificate Authority 112 generates and issues the certificate, which is returned to the user terminal 104. The user terminal 104 can then utilize the digital certificate to carry out the transaction with another entity such as remote server 116. Such transactions may include financial transactions or any other transaction in which the identity of the user terminal 104 should be reliably authenticated.
When user terminal 104 sends the digital certificate to remote server 116, the remote server 116 can inspect the digital certificate against a list of revoked certificates (the Certificate Revocation List) stored by the remote server 116. In the event remote server 116 has not obtained a recent CRL, one can be requested from the Certificate Authority 112. Certificate Authority 112 then either generates a new CRL or sends the most recently generated CRL to the remote server 116. Remote server 116 can then determine whether nor not the digital certificate sent by user terminal 104 is valid. Thus, remote server 116 can authenticate the user terminal 104 and determine whether or not to authorize particular transaction at hand.
FIG. 2 depicts a message flow diagram 200 for the transaction just described. In this message flow diagram, a certificate request 204 is sent from the user terminal 104 to the Certificate Authority 112. The Certificate Authority 112 generates a certificate at 208 and returns the certificate at 212 to the user terminal 104. The user terminal 104 can then submit a transaction using the certificate at 218 to the remote server 116. Remote server 116 can then request a new CRL at 222 of the Certificate Authority. The Certificate Authority 112 then generates or retrieves a CRL at 226 and sends the CRL to the remote server 116 at 230. Depending on the nature of the transaction, the remote server 116 may process the CRL at 232 by taking various actions including, for example, sorting, filtering or reformatting the CRL and storing information in its own database. At 234, the certificate can be authenticated against the CRL data at the remote server 116. At 238 the transaction can be either approved or rejected in accordance with the authentication at 234 and at 242 the approval or rejection can be confirmed with the user terminal 104. Those skilled in the art will recognize that many other message flows are possible with the message flow 200 if FIG. 2 being intended as exemplary of a simple use of a digital certificate and a Certificate Revocation List.
With reference to FIG. 3 the Certificate Authority 112 may generate the Certificate Revocation List in accordance with process 300. CRLs are generated at the Certificate Authority either on a periodic basis, or as a result of some event such as a certificate revocation, or some combination thereof. The process starts at 302 after which a database of certificates is queried for certificates meeting a particular criteria of inactivity. One example is for the query to request all certificates that have been revoked. Other certificates are assumed to still be valid and active.
At 304 the certificate database at the Certificate Authority responds to the query with certificates meeting the specified criteria. Header information is then generated, for example, in accordance with X.509 and RFC 2459 standards (or other applicable CRL standards) at 312 and at 316 the certificate is formatted (for example, as an ASN.1 or other format CRL.) The digital certificate is signed at 320 to assure its authenticity and is then stored at 322 within a computer residing at the Certificate Authority. The process returns at 326. Whenever a request is made for a new digital certificate, process 300 is carried out or, in some instances, the most recently generated CRL may be retrieved and forwarded to the requester.
As digital certificates find wider use, the number of such certificates issued has increased dramatically. With this increase comes an associated increase in the number of entries in a Certificate Revocation List. Accordingly, the process 300 as just described can become an extremely time consuming process that can result in the CRL being untimely in that many minutes or even hours can pass before an updated CRL can be generated. This is obviously undesirable since the process of authentication using the CRL should preferably be carried out on the most recent information available.
In addition to the certificate revocation list just described, certificate authorities commonly generate a certificate revocation list that is referred to as a delta CRL or ΔCRL. A delta CRL is simply a type of CRL that reflects changes made between two consecutive CRLs. Delta CLRs can be generated, for example, using process 300 wherein the query of 304 is a query that further limits the selection criterion to digital certificates that have been changed since the most recently generated CRL (or between two adjacent CRLs).
The concept of delta CRLs is illustrated in FIG. 4 by a sequence of CRLs numbered 1, 2, 3 and 4 with delta CRLs (504, 506 and 508) spanning CRL #1 and CRL #2, CRL #2 and CRL #3, and CRL #3 and CRL #4. With reference to FIG. 2, when a delta CRL is sent at 230, one portion of the processing of the delta CRL at 232 is to retain the data from the most recent CRL while appending the appropriate delta CRL to the existing CRL to update the list of revoked certificates.